<?xml version="1.0" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Ganglia</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<link rev="made" href="mailto:root@localhost" />
</head>

<body style="background-color: white">


<!-- INDEX BEGIN -->
<div name="index">
<p><a name="__index__"></a></p>

<ul>

	<li><a href="#name">Name</a></li>
	<li><a href="#version">Version</a></li>
	<li><a href="#synopsis">Synopsis</a></li>
	<li><a href="#installation">Installation</a></li>
	<ul>

		<li><a href="#monitoring_core_installation">Monitoring Core Installation</a></li>
		<li><a href="#php_web_frontend_installation">PHP Web Frontend Installation</a></li>
	</ul>

	<li><a href="#configuration">Configuration</a></li>
	<ul>

		<li><a href="#gmond_configuration">Gmond Configuration</a></li>
		<li><a href="#gmetad_configuration">Gmetad Configuration</a></li>
		<li><a href="#php_web_frontend_configuration">PHP Web Frontend Configuration</a></li>
	</ul>

	<li><a href="#commandline_tools">Commandline Tools</a></li>
	<ul>

		<li><a href="#gmetric">Gmetric</a></li>
		<li><a href="#gstat">Gstat</a></li>
	</ul>

	<li><a href="#extending_ganglia_through_metric_modules">Extending Ganglia through metric modules</a></li>
	<li><a href="#frequently_asked_questions__faq_">Frequently Asked Questions (FAQ)</a></li>
	<li><a href="#getting_support">Getting Support</a></li>
	<li><a href="#copyright">Copyright</a></li>
	<li><a href="#authors">Authors</a></li>
	<li><a href="#contributors">Contributors</a></li>
</ul>

<hr name="index" />
</div>
<!-- INDEX END -->

<p>
</p>
<hr />
<h1><a name="name">Name</a></h1>
<p><strong>ganglia</strong> - distributed monitoring system</p>
<p>
</p>
<hr />
<h1><a name="version">Version</a></h1>
<p><strong>ganglia</strong> 3.1.7</p>
<p>The latest version of this software and document will always be found at 
<a href="http://ganglia.sourceforge.net/.">http://ganglia.sourceforge.net/.</a>  You are currently reading
$Revision: 2209 $ of this document.</p>
<p>
</p>
<hr />
<h1><a name="synopsis">Synopsis</a></h1>
<pre>
     ______                  ___
    / ____/___ _____  ____ _/ (_)___ _
   / / __/ __ `/ __ \/ __ `/ / / __ `/
  / /_/ / /_/ / / / / /_/ / / / /_/ /
  \____/\__,_/_/ /_/\__, /_/_/\__,_/
                   /____/ Distributed Monitoring System</pre>
<p>Ganglia is a scalable distributed monitoring system for high-performance computing systems 
such as clusters and Grids. It is based on a hierarchical design targeted at federations of 
clusters. It relies on a multicast-based listen/announce protocol to monitor state within 
clusters and uses a tree of point-to-point connections amongst representative cluster nodes 
to federate clusters and aggregate their state. It leverages widely used technologies such as 
XML for data representation, XDR for compact, portable data transport, and RRDtool for data 
storage and visualization. It uses carefully engineered data structures and algorithms to 
achieve very low per-node overheads and high concurrency. The implementation is robust, has 
been ported to an extensive set of operating systems and processor architectures, and is 
currently in use on over 500 clusters around the world. It has been used to link clusters 
across university campuses and around the world and can scale to handle clusters with 2000 nodes.</p>
<p>The ganglia system is comprised of two unique daemons, a PHP-based web frontend and a few other
small utility programs.</p>
<dl>
<dt><strong><a name="daemon" class="item"><strong>Ganglia Monitoring Daemon (gmond)</strong></a></strong></dt>

<dd>
<p>Gmond is a multi-threaded daemon which runs on each cluster node you want to monitor. 
Installation is easy. You don't have to have a common NFS filesystem or a database backend, 
install special accounts, maintain configuration files or other annoying hassles.</p>
<p>Gmond has four main responsibilities: monitor changes in host state, announce relevant changes, 
listen to the state of all other ganglia nodes via a unicast or multicast channel and answer requests for 
an XML description of the cluster state.</p>
<p>Each gmond transmits in information in two different ways: unicasting/multicasting host state in external data 
representation (XDR) format using UDP messages or sending XML over a TCP connection.</p>
</dd>
<dt><strong><strong>Ganglia Meta Daemon (gmetad)</strong></strong></dt>

<dd>
<p>Federation in Ganglia is achieved using a tree of point-to-point
connections amongst representative cluster nodes to aggregate the
state of multiple clusters.  At each node in the tree, a Ganglia Meta
Daemon (<code>gmetad</code>) periodically polls a collection of child data
sources, parses the collected XML, saves all numeric, volatile metrics
to round-robin databases and exports
the aggregated XML over a TCP sockets to clients.  Data sources may be either
<code>gmond</code> daemons, representing specific clusters, or other
<code>gmetad</code> daemons, representing sets of clusters. Data sources
use source IP addresses for access control and can be specified using
multiple IP addresses for failover. The latter capability is natural
for aggregating data from clusters since each <code>gmond</code> daemon
contains the entire state of its cluster.</p>
</dd>
<dt><strong><a name="ganglia_php_web_frontend" class="item"><strong>Ganglia PHP Web Frontend</strong></a></strong></dt>

<dd>
<p>The Ganglia web frontend provides a view of the gathered information 
via real-time dynamic web pages. Most importantly, it displays Ganglia 
data in a meaningful way for system administrators and computer users. 
Although the web frontend to ganglia started as a simple HTML view of the 
XML tree, it has evolved into a system that keeps a colorful history of 
all collected data.</p>
<p>The Ganglia web frontend caters to system administrators and users. For 
example, one can view the CPU utilization over the past hour, day, week, 
month, or year. The web frontend shows similar graphs for Memory usage, 
disk usage, network statistics, number of running processes, and all other 
Ganglia metrics.</p>
<p>The web frontend depends on the existence of the <code>gmetad</code> which provides it 
with data from several Ganglia sources. Specifically, the web frontend will 
open the local port 8651 (by default) and expects to receive a Ganglia XML tree. 
The web pages themselves are highly dynamic; any change to the Ganglia data appears 
immediately on the site. This behavior leads to a very responsive site, but requires 
that the full XML tree be parsed on every page access. Therefore, the Ganglia web 
frontend should run on a fairly powerful, dedicated machine if it presents a large 
amount of data.</p>
<p>The Ganglia web frontend is written in the PHP scripting language, and uses graphs 
generated by <code>gmetad</code> to display history information. It has been tested on many 
flavours of Unix (primarily Linux) with the Apache webserver and the PHP module (4.1 or later).</p>
</dd>
</dl>
<p>
</p>
<hr />
<h1><a name="installation">Installation</a></h1>
<p>The latest version of all ganglia software can always be downloaded from <a href="http://ganglia.info/">http://ganglia.info/</a></p>
<p>Ganglia runs on Linux (i386, ia64, sparc, alpha, powerpc, m68k, mips, arm, hppa, s390), 
FreeBSD, NetBSD, OpenBSD, DragonflyBSD, MacOS X, Solaris, AIX, IRIX, Tru64, HPUX and Windows NT/XP/2000/2003/2008 making it as 
portable as it is scalable.</p>
<p>
</p>
<h2><a name="monitoring_core_installation">Monitoring Core Installation</a></h2>
<p>If you use the Linux RPMs provided on the ganglia web site, you can skip 
to the end of this section.</p>
<p>Ganglia uses the GNU autoconf so compilation and installation of the monitoring core is basically</p>
<pre>
  % ./configure
  % make
  % make install</pre>
<p>but there are some issues that you need to take a look at first.</p>
<dl>
<dt><strong><a name="kernel_multicast_support" class="item"><strong>Kernel multicast support</strong></a></strong></dt>

<dd>
<p>If you use the ganglia multicast support, you must have a kernel that 
supports multicast.  The
vast majority of machines have multicast support by default.  If you have
problems with ganglia this is a core issue.</p>
</dd>
<dt><strong><a name="gmetad_is_not_installed_by_default" class="item"><strong>Gmetad is not installed by default</strong></a></strong></dt>

<dd>
<p>Since <code>gmetad</code> relies on the Round-Robin Database Tool ( see <a href="http://www.rrdtool.org/">http://www.rrdtool.org/</a> )
it will not be compiled unless you explicit request it by using a <strong>--with-gmetad</strong> flag.</p>
<pre>
  % ./configure --with-gmetad</pre>
<p>The configure script will fail if it cannot find the rrdtool library and header files.
By default, it expects to find them at /usr/include/rrd.h and
/usr/lib/librrd.so.
If you installed them in different locations then you need to instruct
configure where to find them using:</p>
<pre>
  % ./configure --with-librrd=/rrd/path --with-gmetad</pre>
<p>Of course, you need to substitute <code>/rrd/path</code> with the real location of the
rrd tool directory where the header file can be located inside an include
subdirectory and the library can be located inside a lib subdirectory.
As an alternative you could set &quot;-L&quot; in LDFLAGS, and &quot;-I&quot; in CFLAGS and
CPPFLAGS for the library path and the header path respectively.</p>
</dd>
<dt><strong><a name="aix_should_not_be_compiled_with_shared_libraries" class="item"><strong>AIX should not be compiled with shared libraries</strong></a></strong></dt>

<dd>
<p>You must add the <code>--disable-shared</code> configure flags if you are running on AIX.
For more details refer to the README.AIX file</p>
<pre>
  % ./configure --disable-shared</pre>
</dd>
<dt><strong><a name="solaris_dependencies_could_be_problematic" class="item"><strong>Solaris dependencies could be problematic</strong></a></strong></dt>

<dd>
<p>Not really a Solaris specific problem, but since Solaris has several different
package repositories, all of them unofficial, it is difficult to be sure
that all possible permutations have been confirmed to work reliably.</p>
<p>Be sure to have all dependencies covered, as explained in the INSTALL file and
to use GNU make and a gcc compiler that builds 32bit binaries with all other
libraries matching that ISA.</p>
<p>When in doubt, build the problematic dependency from source and remember
to distribute it together with your ganglia build as everything is dynamically
linked by default.</p>
<p>Be particularly careful with libConfuse, especially if using the old 2.5 version.
LibConfuse 2.5 is known to be incorrectly packaged and to compile by default
as a static library which will fail to link with ganglia.</p>
</dd>
<dt><strong><a name="propietary_nix_systems_might_not_work_at_all" class="item"><strong>Propietary *NIX systems might not work at all</strong></a></strong></dt>

<dd>
<p>The good news is that the libmetrics code that used to work before 3.1 is
still most likely working fine and so there is nothing fundamentally broken
about it.</p>
<p>But the bad news is that in order to add the dynamic metric functionality,
the build system and the way gmond used to locate its metrics had to be
changed significantly. Therefore getting gmond to build and work again 
required fixes to be implemented for all platforms.</p>
<p>Since none of the developers had access to HPUX, IRIX, Tru64 (OSF/1), or Darwin
(MacOS X) those platforms might not be able to build or run a 3.1 gmond
yet. If you have access to any of these platforms and want to run ganglia 3.1,
feel free to drop by the ganglia-developers list with suggestions, or even
better patches.</p>
</dd>
<dt><strong><a name="gexec_confusion" class="item"><strong>GEXEC confusion</strong></a></strong></dt>

<dd>
<p>GEXEC is a scalable cluster remote execution system which provides fast, RSA authenticated 
remote execution of parallel and distributed jobs. It provides transparent forwarding of 
stdin, stdout, stderr, and signals to and from remote processes, provides local environment 
propagation, and is designed to be robust and to scale to systems over 1000 nodes. Internally, 
GEXEC operates by building an n-ary tree of TCP sockets and threads between gexec daemons and 
propagating control information up and down the tree. By using hierarchical control, GEXEC 
distributes both the work and resource usage associated with massive amounts of parallelism 
across multiple nodes, thereby eliminating problems associated with single node resource limits 
(e.g., limits on the number of file descriptors on front-end nodes). 
(from <a href="http://www.theether.org/gexec">http://www.theether.org/gexec</a> )</p>
<p><code>gexec</code> is a great cluster execution tool but integrating it with ganglia is a bit clumsy.
GEXEC can run standalone without access to a ganglia <code>gmond</code>.  In standalone
mode gexec will use the hosts listed in your GEXEC_SVRS variable to run on.  For example,
say I want to run <code>hostname</code> on three machines in my cluster: <code>host1</code>, <code>host2</code> and <code>host3</code>.
I use the following command line.</p>
<pre>
  % GEXEC_SVRS=&quot;host1 host2 host3&quot; gexec -n 3 hostname</pre>
<p>and gexec would build an n-ary tree (binary tree by default) of TCP sockets to those machines
and run the command <code>hostname</code></p>
<p>As an added feature, you can have <code>gexec</code> pull a host list from a locally running gmond and
use that as the host list instead of GEXEC_SVRS.  The list is load balanced and <code>gexec</code> will
start the job on the <em>n</em> least-loaded machines.</p>
<p>For example..</p>
<pre>
  % gexec -n 5 hostname</pre>
<p>will run the command <code>hostname</code> on the five least-loaded machines in a cluster.</p>
<p>To turn on the <code>gexec</code> feature in ganglia you must configure ganglia with the <code>--enable-gexec</code>
flag</p>
<pre>
  % ./configure --enable-gexec</pre>
<p>Enabling <code>gexec</code> means that by default any host running gmond will send a special
message announcing that gexec is installed on it and open for requests.</p>
<p>Now the question is, what if I don't want gexec to run on every host in my cluster?  For
example, you may not want to have <code>gexec</code> run jobs on your cluster frontend nodes.</p>
<p>You simply add the following line to your <code>gmond</code> configuration file (<code>/etc/ganglia/gmond.conf</code> by
default)</p>
<pre>
  no_gexec on</pre>
<p>Simple huh?  I know the configuration file option, <code>no_gexec</code>, seems crazy (and it is).  Why
have an option that says &quot;yes to no gexec&quot;?  The early versions of gmond didn't use a configuration
file but instead commandline options.  One of the commandline options was simply <code>--no-gexec</code>
and the default was to announce gexec as on.</p>
</dd>
</dl>
<p>Once you have successfully run</p>
<pre>
  % ./configure &lt;options&gt;
  % make
  % make install</pre>
<p>you should find the following files installed in <code>/usr</code> (by default).</p>
<pre>
  /usr/bin/gstat
  /usr/bin/gmetric
  /usr/sbin/gmond
  /usr/sbin/gmetad</pre>
<p>If you installed ganglia using RPMs then these files will be installed when you install
the RPM.  The RPM is installed simply by running</p>
<pre>
  % rpm -Uvh ganglia-gmond-3.1.7.i386.rpm
  % rpm -Uvh ganglia-gmetad-3.1.7.i386.rpm</pre>
<p>Once you have the necessary binaries installed, you can test your installation by running</p>
<pre>
   % ./gmond</pre>
<p>This will start the ganglia monitoring daemon.  You should then be able to run</p>
<pre>
   % telnet localhost 8649</pre>
<p>And get an XML description of the state of your machine (and any other hosts running gmond
at the time).</p>
<p>If you are installing by source on Linux, scripts are provided to start <code>gmetad</code> and <code>gmond</code>
at system startup.  They are easy to install from the source root.</p>
<pre>
   % cp ./gmond/gmond.init /etc/rc.d/init.d/gmond
   % chkconfig --add gmond
   % chkconfig --list gmond
     gmond              0:off   1:off   2:on    3:on    4:on    5:on    6:off
   % /etc/rc.d/init.d/gmond start
     Starting GANGLIA gmond:                                    [  OK  ]</pre>
<p>Repeat this step with gmetad.</p>
<p>
</p>
<h2><a name="php_web_frontend_installation">PHP Web Frontend Installation</a></h2>
<ol>
<li>
<p>The <strong>./web</strong> directory of the ganglia distribution contains all the necessary PHP files for
running your web frontend.  Copy those files to <code>/var/www/html</code>, however look for the variable 
<code>DocumentRoot</code> in your Apache configuration 
files to be sure. All the PHP script files use relative URLs in their links, so you may 
place the <code>ganglia/</code> directory anywhere convenient.</p>
</li>
<li>
<p>Ensure your webserver understands how to process PHP script files. Currently, the 
web frontend contains certain php language that requires PHP version 4 or greater. 
Processing PHP script files usually requires a webserver module, such as the 
<code>mod_php</code> for the popular Apache webserver. In RedHat Linux, the RPM package that 
provides this module is called simply &quot;php&quot;.</p>
<p>For Apache, <code>mod_php</code> module must be enabled. The following lines should appear 
somewhere in Apache's *conf files. This example applies to RedHat and Mandrake 
Linux. The actual filenames may vary on your system. If you installed the php 
module using an RPM package, this work will have been done automatically.</p>
<pre>
  &lt;IfDefine HAVE_PHP4&gt;
  LoadModule php4_module    extramodules/libphp4.so
  AddModule mod_php4.c
  &lt;/IfDefine&gt;</pre>
<pre>
  AddType  application/x-httpd-php         .php .php4 .php3 .phtml
  AddType  application/x-httpd-php-source  .phps</pre>
</li>
<li>
<p>The webfrontend requires the existance of the gmetad package on the webserver. 
Follow the installation instructions on the gmetad page. Specifically, the webfrontend 
requires the rrdtool and the <code>rrds/</code> directory from gmetad. If you are a power user, 
you may use NFS to simulate the local existance of the rrds.</p>
</li>
<li>
<p>Test your installation. Visit the URL:</p>
<pre>
  <a href="http://localhost/ganglia/">http://localhost/ganglia/</a></pre>
<p>With a web-browser, where localhost is the address of your webserver.</p>
</li>
</ol>
<p>Installation of the web frontend is simplified on Linux by using rpm.</p>
<pre>
  % rpm -Uvh ganglia-web-3.1.7-1.i386.rpm
  Preparing...                ########################################### [100%]
     1:ganglia-web            ########################################### [100%]</pre>
<p>
</p>
<hr />
<h1><a name="configuration">Configuration</a></h1>
<p>
</p>
<h2><a name="gmond_configuration">Gmond Configuration</a></h2>
<p>The configuration file format has changed between gmond version 2.5.x and version
3.x.  The change was necessary in order to allow more complex configuration options.</p>
<p>Gmond has a default configuration it will use if it does not find the default configuration
file <strong>/etc/ganglia/gmond.conf</strong>.  To see the default configuration simply run the command:</p>
<pre>
  % gmond --default_config</pre>
<p>and gmond will output its default configuration to stdout.  This default configuration can
serve as a good starting place for building a more custom configuration.</p>
<pre>
  % gmond --default_config &gt; gmond.conf</pre>
<p>would create a file <strong>gmond.conf</strong> which you can then edit to taste and copy to <strong>/etc/ganglia/gmond.conf</strong>
or elsewhere.</p>
<p>To start gmond with a configuration file other then <strong>/etc/ganglia/gmond.conf</strong>, simply specify the
configuration file location by running</p>
<pre>
  % gmond --config /my/ganglia/configs/custom.conf</pre>
<p>If you want to convert a 2.5.x configuration file to 3.x file format, run the following command</p>
<pre>
  % gmond --convert ./old_25_config.conf</pre>
<p>and gmond with output the equivalent 3.x configuration file to stdout.  You can then redirect
that output to a new configuration file which can serve as a starting point for your configuration.</p>
<pre>
  % gmond --convert ./old_25_config.conf &gt; ./new_26_config.conf</pre>
<p>For details about gmond configuration options, simply run</p>
<pre>
  % man gmond.conf</pre>
<p>for a complete listing of options with detailed explanations.</p>
<p>
</p>
<h2><a name="gmetad_configuration">Gmetad Configuration</a></h2>
<p>The behavior of the Ganglia Meta Daemon is completely controlled by a single configuration 
file which is by default <code>/etc/ganglia/gmetad.conf</code>. For gmetad to do anything useful you much 
specify at least one <code>data_source</code> in the configuration. The format of the data_source 
line is as follows</p>
<pre>
  data_source &quot;Cluster A&quot; 127.0.0.1  1.2.3.4:8655  1.2.3.5:8625
  data_source &quot;Cluster B&quot; 1.2.4.4:8655</pre>
<p>In this example, there are two unique data sources: &quot;Cluster A&quot; and &quot;Cluster B&quot;. The 
Cluster A data source has three redundant sources. If gmetad cannot pull the data 
from the first source, it will continue trying the other sources in order.</p>
<p>If you do not specify a port number, gmetad will assume the default ganglia port which
is 8649 (U*N*I*X on a phone key pad)</p>
<p>For a sample gmetad configuration file with comments, look at the gmetad.conf
file provided as part of the distribution package in the gmetad directory</p>
<p><code>gmetad</code> has a <code>--conf</code> option to allow you to specify alternate configuration files</p>
<pre>
  % ./gmetad -conf=/tmp/my_custom_config.conf</pre>
<p>
</p>
<h2><a name="php_web_frontend_configuration">PHP Web Frontend Configuration</a></h2>
<p>Most configuration parameters reside in the <code>ganglia/conf.php</code> file. Here you 
may alter the template, gmetad location, RRDtool location, and set the default time range 
and metrics for graphs.</p>
<p>The static portions of the Ganglia website are themable. This means you can alter elements 
such as section lables, some links, and images to suit your individual tastes and environment. 
The <code>template_name</code> variable names a directory containing the current theme. Ganglia uses 
TemplatePower to implement themes. A user-defined skin must conform to the template interface 
as defined by the default theme. Essentially, the variable names and START/END blocks in a 
custom theme must remain the same as the default, but all other HTML elements may be changed.</p>
<p>Other configuration variables in <code>conf.php</code> specify the location of gmetad's files, and where 
to find the rrdtool program. These locations need only be changed if you do not run gmetad on 
the webserver. Otherwise the default locations should work fine. The <code>default_range</code> variable 
specifies what range of time to show on the graphs by default, with possible values of hour, 
day, week, month, year. The <code>default_metric</code> parameter specifies which metric to show on 
the cluster view page by default.</p>
<p>
</p>
<hr />
<h1><a name="commandline_tools">Commandline Tools</a></h1>
<p>There are two commandline tools that work with <code>gmond</code> to add custom metrics and
query the current state of a cluster: <code>gmetric</code> and <code>gstat</code> respectively.</p>
<p>
</p>
<h2><a name="gmetric">Gmetric</a></h2>
<p>The <strong>Ganglia Metric Tool (gmetric)</strong> allows you to easily monitor any arbitrary 
host metrics that you like expanding on the core metrics that gmond measures by default.</p>
<p>If you want help with the gmetric sytax, simply use the &quot;help&quot; commandline option</p>
<pre>
  % gmetric --help
  gmetric 3.1.7</pre>
<pre>
  Purpose:
    The Ganglia Metric Client (gmetric) announces a metric
    on the list of defined send channels defined in a configuration file</pre>
<pre>
  Usage: gmetric [OPTIONS]...</pre>
<pre>
    -h, --help          Print help and exit
    -V, --version       Print version and exit
    -c, --conf=STRING   The configuration file to use for finding send channels
                        (default=`/etc/ganglia/gmond.conf')
    -n, --name=STRING   Name of the metric
    -v, --value=STRING  Value of the metric
    -t, --type=STRING   Either
                        string|int8|uint8|int16|uint16|int32|uint32|float|double
    -u, --units=STRING  Unit of measure for the value e.g. Kilobytes, Celcius
                        (default=`')
    -s, --slope=STRING  Either zero|positive|negative|both  (default=`both')
    -x, --tmax=INT      The maximum time in seconds between gmetric calls
                        (default=`60')
    -d, --dmax=INT      The lifetime in seconds of this metric  (default=`0')
    -S, --spoof=STRING  IP address and name of host/device (colon separated) we
                          are spoofing  (default='')
    -H, --heartbeat     spoof a heartbeat message (use with spoof option)</pre>
<p>Gmetric sends the metric specified on the commandline to all <strong>udp_send_channel</strong>s specified
in the configuration file <strong>/etc/ganglia/gmond.conf</strong> by default.  If you want to send metric to 
alternate <strong>udp_send_channel</strong>s, you can specify a different configuration file as such:</p>
<pre>
  % gmetric --conf=./custom.conf -n &quot;wow&quot; -v &quot;it works&quot; -t &quot;string&quot;</pre>
<p>All metrics in ganglia have a name, value, type and optionally units. For example, say I wanted 
to measure the temperature of my CPU (something gmond doesn't do by default) then I could 
send this metric with name=&quot;temperature&quot;, value=&quot;63&quot;, type=&quot;int16&quot; and units=&quot;Celcius&quot;.</p>
<p>Assume I have a program called <code>cputemp</code> which outputs in text the temperature of the CPU</p>
<pre>
  % cputemp
  63</pre>
<p>I could easily send this data to all listening gmonds by running</p>
<pre>
  % gmetric --name temperature --value `cputemp` --type int16 --units Celcius</pre>
<p>Check the exit value of gmetric to see if it successfully sent the data: 0 on success and -1 on failure.</p>
<p>To constantly sample this temperature metric, you just need too add this command to your cron table.</p>
<p>
</p>
<h2><a name="gstat">Gstat</a></h2>
<p>The Ganglia Cluster Status Tool (gstat) is a commandline utility that allows you to get status 
report for your cluster.</p>
<p>To get help with the commandline options, simply pass <code>gstat</code> the <code>--help</code> option</p>
<pre>
  % gstat --help
  gstat 3.1.7</pre>
<pre>
  Purpose:
    The Ganglia Status Client (gstat) connects with a
    Ganglia Monitoring Daemon (gmond) and output a load-balanced list
    of cluster hosts</pre>
<pre>
  Usage: gstat [OPTIONS]...
     -h         --help             Print help and exit
     -V         --version          Print version and exit
     -a         --all              List all hosts.  Not just hosts running gexec (default=off)
     -d         --dead             Print only the hosts which are dead (default=off)
     -m         --mpifile          Print a load-balanced mpifile (default=off)
     -1         --single_line      Print host and information all on one line (default=off)
     -l         --list             Print ONLY the host list (default=off)
     -n         --numeric          Print numeric addresses instead of hostnames (default=off)
     -iSTRING   --gmond_ip=STRING  Specify the ip address of the gmond to query (default='127.0.0.1')
     -pINT      --gmond_port=INT   Specify the gmond port to query (default=8649)</pre>
<p>Note: gstat with no option will only show gexec-enabled hosts.  To see all hosts that are UP (regardless
of their gexec state) you need to add the <strong>--all</strong> flag.</p>
<pre>
  % gstat --all</pre>
<p>
</p>
<hr />
<h1><a name="extending_ganglia_through_metric_modules">Extending Ganglia through metric modules</a></h1>
<p>There are currently two ways in which metric modules can be written and plugged into Gmond in order 
to extend the types of metrics that Ganglia is able to monitor.  As of Ganglia 3.1, a pluggable 
interface has been added to allow the Gmond metric gathering agent to collect any type of metric 
that can be acquired through programatic means.  The primary metric module interface is C with a 
secondary python interface.  This means that pluggable modules can either be written and compiled 
into dynamically loadable C based language modules or written and deployed as python pluggable modules.</p>
<p>The basic steps when writting a pluggable module either in C or in python, is as follows:</p>
<ol>
<li><strong><a name="create_a_module_definition_structure_that_contains_callback_data_and_metric_information" class="item">Create a module definition structure that contains callback data and metric information</a></strong>

</li>
<li><strong><a name="implement_3_callback_functions_that_will_serve_as_the_links_between_the_gmond_metric_gathering_agent_and_the_metric_module_these_callback_functions_include_module_initialization_metric_handler_and_module_cleanup" class="item">Implement 3 callback functions that will serve as the links between the Gmond metric 
gathering agent and the metric module.  These callback functions include module initialization, 
metric handler and module cleanup.</a></strong>

</li>
</ol>
<p>There are simple metric module examples for both a C based and a python based module under the 
gmond/modules and gmond/python_modules source code sub-trees.  Please see these module examples for
more details.</p>
<p>
</p>
<hr />
<h1><a name="frequently_asked_questions__faq_">Frequently Asked Questions (FAQ)</a></h1>
<dl>
<dt><strong><a name="what_metrics_does_ganglia_collect_on_platform_x" class="item"><strong>What metrics does ganglia collect on platform x?</strong></a></strong></dt>

<dd>
<p>To see a complete list of the metrics
that a particular gmond supports, run the command:</p>
<pre>
  % gmond -m</pre>
<p>and gmond will output all the metrics that it is capable of collecting 
and sending.</p>
<p>This table describes all the metrics that ganglia collects and
shows what platforms the metric are supported on.  (The following table
is only partially complete).</p>
<pre>
  Metric Name    Description                             Platforms
  -----------------------------------------------------------------------
  boottime      System boot timestamp                    l,f
  bread_sec
  bwrite_sec
  bytes_in      Number of bytes in per second            l,f
  bytes_out     Number of bytes out per second           l,f
  cpu_aidle     Percent of time since boot idle CPU      l
  cpu_arm
  cpu_avm
  cpu_idle      Percent CPU idle                         l,f
  cpu_intr
  cpu_nice      Percent CPU nice                         l,f
  cpu_num       Number of CPUs                           l,f
  cpu_rm
  cpu_speed     Speed in MHz of CPU                      l,f
  cpu_ssys
  cpu_system    Percent CPU system                       l,f
  cpu_user      Percent CPU user                         l,f
  cpu_vm
  cpu_wait
  cpu_wio
  disk_free     Total free disk space                    l,f
  disk_total    Total available disk space               l,f
  load_fifteen  Fifteen minute load average              l,f
  load_five     Five minute load average                 l,f
  load_one      One minute load average                  l,f
  location      GPS coordinates for host                 e
  lread_sec
  lwrite_sec
  machine_type
  mem_buffers   Amount of buffered memory                l,f
  mem_cached    Amount of cached memory                  l,f
  mem_free      Amount of available memory               l,f
  mem_shared    Amount of shared memory                  l,f
  mem_total     Amount of available memory               l,f
  mtu           Network maximum transmission unit        l,f
  os_name       Operating system name                    l,f
  os_release    Operating system release (version)       l,f
  part_max_used Maximum percent used for all partitions  l,f
  phread_sec
  phwrite_sec
  pkts_in       Packets in per second                    l,f
  pkts_out      Packets out per second                   l,f
  proc_run      Total number of running processes        l,f
  proc_total    Total number of processes                l,f
  rcache
  swap_free     Amount of available swap memory          l,f
  swap_total    Total amount of swap memory              l,f
  sys_clock     Current time on host                     l,f
  wcache</pre>
<pre>
  Platform key:
  l = Linux, f = FreeBSD, a = AIX, c = Cygwin
  m = MacOS, i = IRIX, h = HPUX,  t = Tru64
  e = Every Platform</pre>
<p>If you are interested in <strong>how</strong> the metrics are collected, just
take a look in directory <code>./libmetrics</code> in the source distribution.
There is a directory for each platform that is supported.</p>
</dd>
<dt><strong><a name="xml" class="item"><strong>What does the error &quot;Process XML (x): XML_ParseBuffer() error at line x: not well-formed&quot;</strong></a></strong></dt>

<dd>
<p>This is an error that occurs when a ganglia components reads data from another ganglia component
and finds that the XML is not well-formed.  The most common time this is a problem is when the PHP
web frontend tries to read the XML stream from gmetad.</p>
<p>To troubleshoot this problem, capture an XML from the ganglia component in question (gmetad/gmond).
This is easy to do if you have telnet installed.  Simply login to the machine running the 
component and run.</p>
<pre>
  % telnet localhost 8651</pre>
<p>By default, gmetad exports its XML on port 8651 and gmond exports its XML on port 8649.  Modify
the port number above to suite your configuration.</p>
<p>When you connect to the port you should get an XML stream.  If not, look in the process table on
the machine to ensure that the component is actually running.</p>
<p>Once you are getting an XML stream, capture it to a file by running.</p>
<pre>
  % telnet localhost 8651 &gt; XML.txt
  Connection closed by foreign host.</pre>
<p>If you open the file <code>XML.txt</code>, you will see the captured XML stream.  You will need to remove
the first three lines of the <code>XML.txt</code> which will read...</p>
<pre>
  Trying 127.0.0.1...
  Connected to localhost.
  Escape character is '^]'.</pre>
<p>Those lines are output from <code>telnet</code> and not the ganglia component (I wish telnet would send
those messages to <code>stderr</code> but they are send to <code>stdout</code>).</p>
<p>There are many ways that XML can be misformed.  The great tool for validating XML is <code>xmllint</code>.
<code>xmllint</code> will read the file and find the line containing the error.</p>
<pre>
  % xmllint --valid --noout XML.txt</pre>
<p>will read your captured XML stream, validate it against the ganglia DTD and check that it is 
well-formed XML.  <code>xmllint</code> will quiet exit if there are no errors.  If 
there are errors they will be reported with line numbers.  For example...</p>
<pre>
  /tmp/XML.txt:3393: error: Opening and ending tag mismatch: HOST and CLUSTER
  &lt;/CLUSTER&gt;
         ^
  /tmp/XML.txt:3394: error: Opening and ending tag mismatch: CLUSTER and GANGLIA_XML
  &lt;/GANGLIA_XML&gt;
             ^
  /tmp/XML.txt:3395: error: Premature end of data in tag GANGLIA_XML</pre>
<p>If you get errors, open <code>XML.txt</code> and go to the line numbers in question.  See if you can
understand based on your configuration how these errors could occur.  If you cannot fix the
problem yourself, please email your <code>XML.txt</code> and output from <code>xmllint</code> to
<code>ganglia-developers@lists.sourceforge.net</code>.  Please include information about the version
of each component in question along with the operating system they are running on.  The
more details we have about your configuration the more likely it is we will be able to help
you.  Also, all mailing to <code>ganglia-developers</code> is archiving and available to read on the
web.  You may want to modify <code>XML.txt</code> to remove any sensitive information.</p>
</dd>
<dt><strong><a name="how_do_i_remove_a_host_from_the_list" class="item"><strong>How do I remove a host from the list?</strong></a></strong></dt>

<dd>
<p>A common problem that people have is not being able to remove a host from the ganglia
web frontend.</p>
<p>Here is a common scenario</p>
<ol>
<li><strong><a name="all_hosts_in_a_cluster_are_send_on_the_ganglia_udp_send_channels" class="item">All hosts in a cluster are send on the ganglia udp_send_channels.</a></strong>

</li>
<li><strong><a name="one_of_the_hosts_fails_or_is_moved_for_whatever_reason" class="item">One of the hosts fails or is moved for whatever reason.</a></strong>

</li>
<li><strong><a name="all_the_hosts_in_the_cluster_report_that_the_host_is_dead_or_expired" class="item">All the hosts in the cluster report that the host is &quot;dead&quot; or &quot;expired&quot;.</a></strong>

</li>
<li><strong><a name="the_sysadmin_wants_to_removed_this_host_from_the_dead_list" class="item">The sysadmin wants to removed this host from the &quot;dead&quot; list.</a></strong>

</li>
</ol>
<p>Unfortunately there is currently no nice way to remove a single dead host from the list.
All data in gmond is soft state so you will need to restart all gmond and gmetad processes.
It is important to note that ALL dead hosts will be flushed from the record by restarting
the processes (since they have to hear the host at least once to know it is expired).</p>
<p>If you add the line</p>
<pre>
  globals {
    host_dmax = 3600
  }</pre>
<p>then hosts will be removed from host tables when they haven't been heard from in 3600 seconds.
See <code>man gmond.conf</code> for details.</p>
</dd>
<dt><strong><a name="how_good_is_solaris_irix_tru64_support" class="item"><strong>How good is Solaris, IRIX, Tru64 support?</strong></a></strong></dt>

<dd>
<p>Here is an email from Steve Wagner about the state of the ganglia on Solaris, 
IRIX and Tru64. Steve is to thank for porting ganglia to Solaris and Tru64. He also 
helped with the IRIX port.</p>
<pre>
   State of the IRIX port:
   
   *  CPU percentage stuff hasn't improved despite my efforts.  I fear there
      may be a flaw in the way I'm summing counters for all the CPUs.
   *  Auto-detection of network interfaces apparently segfaults.
   *  Memory and load reporting appear to be running properly.
   *  CPU speed is not being reported properly on multi-proc machines.
   *  Total/running processes are not reported.
   *  gmetad untested.
   *  Monitoring core apparently stable in foreground, background being tested
   (had a segfault earlier).
   
   State of the Tru64 port:
   
   *  CPU percentage stuff here works perfectly.
   *  Memory and swap usage stats are suspected to be inaccurate.
   *  Total/running processes are not reported.
   *  gmetad untested.
   *  Monitoring core apparently stable in foreground and background.
   
   State of the Solaris port:
   *  CPU percentages are slightly off, but correct enough for trending
      purposes.
   *  Load, ncpus, CPU speed, breads/writes, lreads/writes, phreads/writes,
      and rcache/wcache are all accurate.
   *  Memory/swap statistics are suspiciously flat, but local stats bear
      this out (and they *are* being updated) so I haven't investigated
      further.
   *  Total processes are counted, but not running ones.
   *  gmetad appears stable
   
   Anyway, all three ports I've been messing with are usable and fairly
   stable.  Although there are areas for improvement I think we really can't
   keep hogging all this good stuff - what I'm looking at is ready for
   release.</pre>
</dd>
<dt><strong><a name="where_are_the_debian_packages" class="item"><strong>Where are the debian packages?</strong></a></strong></dt>

<dd>
<p>Debian packages for 2.5 are available from the main Debian archive for all
releases.</p>
<p>There was never an oficial Debian package for 3.0 and so if you need to use
that branch you will need to build your own binaries.</p>
<p>Packages for 3.1 are available from Debian (and therefore derivative
distributions like Ubuntu) standard repositories.</p>
</dd>
<dt><strong><a name="how_should_i_configure_multihomed_machines" class="item"><strong>How should I configure multihomed machines?</strong></a></strong></dt>

<dd>
<p>Various issues arise when a multihomed machine is running the gmond agent.</p>
<p>Sending multicast packets out on the right interface: the <strong>mcast_if</strong>
option can be declared in the <strong>udp_send_channel</strong> to force outgoing
multicast packets to use a particular interface.  The system administrator
may also be able to make other platform-specific configuration settings
through the OS to achieve the desired behaviour.</p>
<p>Ensuring that outgoing metric packets are always sent with the same
source address: the <strong>bind</strong> and <strong>bind_hostname</strong> parameters are the solution.
Either (but not both) of these can be specified in the <strong>udp_send_channel</strong>
if required.  See the <strong>gmond.conf</strong> man page for details.</p>
<p>Previous advice given in this document suggested adding a route
like so:</p>
<p>route add -host 239.2.11.71 dev eth1</p>
<p>and this method is still valid, but it will be over-ridden by the
<strong>bind</strong> or <strong>bind_hostname</strong> setting.</p>
</dd>
<dt><strong><a name="how_should_i_configure_my_cisco_catalyst_switches" class="item"><strong>How should I configure my Cisco Catalyst Switches?</strong></a></strong></dt>

<dd>
<p>Perhaps information regarding gmond on networks set up through cisco
catalyst switches should be mentioned in the ganglia documentation. I think
by default multicast traffic on the catalyst will flood all devices unless
configured properly. Here is a relavent snipet from a message forum, with a
link to cisco document.</p>
<p>If what you are trying to do, is minimizing the impact on your network due
to a multicast application, this link may describe what you want to do:
<a href="http://www.cisco.com/warp/public/473/38.html">http://www.cisco.com/warp/public/473/38.html</a></p>
<p>We set up our switches according to this after a consultant came in and
installed an application multicasting several hundred packets per second.
This made the network functional again.</p>
</dd>
</dl>
<p>
</p>
<hr />
<h1><a name="getting_support">Getting Support</a></h1>
<pre>
  The tired and thirsty prospector threw himself down at the edge of the 
  watering hole and started to drink. But then he looked around and saw 
  skulls and bones everywhere. &quot;Uh-oh,&quot; he thought. &quot;This watering hole 
  is reserved for skeletons.&quot; --Jack Handey</pre>
<p>There are three mailing lists available to you: <code>ganglia-general</code>, <code>ganglia-developers</code> and 
<code>ganglia-announce</code>.  You can join these lists or read their archives by 
visiting <a href="https://sourceforge.net/mail/?group_id=43021">https://sourceforge.net/mail/?group_id=43021</a></p>
<p><code>All of the ganglia mailing lists are closed</code>.  That means that in order to
post to the lists, you must be subscribed to the list.  We're sorry for the 
inconvenience however it is very easy to subscribe and unsubscribe from the 
lists.  We had to close the mailing lists because of SPAM problems.</p>
<p>When you need help please follow these steps until your problem is resolved.</p>
<ol>
<li>
<p>completely read the documentation</p>
</li>
<li>
<p>check the <code>ganglia-general</code> archive to see if other people have had the same problem</p>
</li>
<li>
<p>post your support request to the <code>ganglia-general</code> mailing list</p>
</li>
<li>
<p>check the <code>ganglia-developers</code> archive</p>
</li>
<li>
<p>post your question to the <code>ganglia-developers</code> list</p>
</li>
</ol>
<p>please send all bugs, patches, and feature requests to the <code>ganglia-developers</code> list 
after you have checked the <code>ganglia-developers</code> archive to see if the question has 
already been asked and answered.</p>
<p>
</p>
<hr />
<h1><a name="copyright">Copyright</a></h1>
<pre>
  Copyright (C) 2002,2003 University of California, Berkeley</pre>
<p>
</p>
<hr />
<h1><a name="authors">Authors</a></h1>
<p>The <strong>Ganglia Development Team</strong>...</p>
<pre>
 Bas van der Vlies      basv               Developer    basv at users.sourceforge.net 
 Neil T. Spring         bluehal            Developer    bluehal at users.sourceforge.net
 Brooks Davis           brooks_en_davis    Developer    brooks_en_davis at users.sourceforge.net
 Eric Fraser            fraze              Developer    fraze at users.sourceforge.net 
 greg bruno             gregbruno          Developer    gregbruno at users.sourceforge.net
 Jeff Layton            laytonjb        Developer       laytonjb at users.sourceforge.net       
 Doc Schneider          maddocbuddha    Developer       maddocbuddha at users.sourceforge.net 
 Mason Katz             masonkatz       Developer       masonkatz at users.sourceforge.net      
 Mike Howard            mhoward         Developer       mhoward at users.sourceforge.net        
 Matt Massie            massie          Project Admin   massie at users.sourceforge.net
 Oliver Mössinger      olivpass        Developer       olivpass at users.sourceforge.net       
 Preston Smith          pmsmith         Developer       pmsmith at users.sourceforge.net        
 Federico David Sacerdoti sacerdoti     Developer       sacerdoti at users.sourceforge.net      
 Tim Cera               timcera         Developer       timcera at users.sourceforge.net        
 Mathew Benson          wintermute11    Developer       wintermute11 at users.sourceforge.net   
 Brad Nicholes          bnicholes       Developer       bnicholes at users.sourceforge.net
 Carlo Arenas           carenas         Developer       carenas at users.sourceforge.net</pre>
<p>
</p>
<hr />
<h1><a name="contributors">Contributors</a></h1>
<p>There have been dozens of contributors who have provided patches and helpful bug reports.  
We need to list them here later.</p>

</body>

</html>
